openai[patch]: support built-in code interpreter and remote MCP tools #31304
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
dosubot
bot
added
size:L
There was a problem hiding this comment.
Pull Request Overview
This PR adds support for OpenAI’s built-in code interpreter and remote MCP tools in the ChatOpenAI responses API integration.
- Introduces new integration tests for code interpreter and MCP flows.
- Updates core request/response handling to include
code_interpreterandmcptool calls. - Extends function-calling utilities and documentation to cover the new built-in tools.
Reviewed Changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| libs/partners/openai/tests/integration_tests/chat_models/test_responses_api.py | Added tests for code interpreter and MCP tool bindings. |
| libs/partners/openai/langchain_openai/chat_models/base.py | Enabled code_interpreter and mcp in bind_tools and request/response builders. |
| libs/core/langchain_core/utils/function_calling.py | Updated convert_to_openai_tool to accept new tool types. |
| docs/docs/integrations/chat/openai.ipynb | Added notebook examples for code interpreter and remote MCP. |
Comments suppressed due to low confidence (2)
libs/partners/openai/tests/integration_tests/chat_models/test_responses_api.py:406
- The
Optionaltype is used here but not imported in this file. Addfrom typing import Optionalto the imports.
full: Optional[BaseMessageChunk] = None
libs/partners/openai/langchain_openai/chat_models/base.py:3169
- Built-in tool calls for
computer_callare collected incomputer_callsbut never appended toinput_. If preservingcomputer_callbehavior, addinput_.extend(computer_calls)alongside the new extends.
input_.extend(code_interpreter_calls)
| " \"role\": \"user\",\n", | ||
| " \"content\": [\n", | ||
| " {\n", | ||
| " \"type\": \"mcp_approval_response\",\n", |
There was a problem hiding this comment.
Do we want to pass it directly in openai's current format or do we want to try to generalize?
There are a lot of ways to represent this part
{
"type": "review",
"approve": True,
}
{
"type": "review",
"action": "approved",
}
Historically choice has always been:
- try to support syntax as closely as possible to provider
- do not generalize from n=1
cc @sydney-runkle worth for you to take a look at the representation as well
dosubot
bot
added
the
lgtm
| # Redact headers from built-in remote MCP tool invocations | ||
| if (tools := params.get("tools")) and isinstance(tools, list): | ||
| params["tools"] = [ | ||
| ({**tool, "headers": "**REDACTED**"} if "headers" in tool else tool) |
There was a problem hiding this comment.
Looks good. The main thing would be if it's possible to make this redaction more prominent (e.g., pull something into a standalone function), so that when one reads this code it's very easy to see that redaction is taking place
No description provided.